TEST_POINT_PROMPT = """
你是一个测试分析专家，请根据以下标准需求文档（SRS）的结构和内容，拆解需求并生成测试点。


重要提示：
1. 仅生成 {{mode}} 中指定的测试类型的测试点
2. 严格忽略 {{mode}} 之外的其他类型需求
3. 如果需求文档包含{{mode}} 之外的其他类型的需求描述，请完全忽略这些部分


测试类型及其范围说明：
（仅当该类型在 {{mode}} 中出现时才考虑以下对应内容）


功能测试：
- 核心功能：基本功能、主要流程
- 边界条件：输入范围、数据限制
- 异常场景：错误处理、异常恢复
- 数据验证：数据格式、有效性
- 业务流程：端到端流程、业务规则
- 数据一致性：数据同步、状态一致
- 国际化与本地化：多语言、地区适配


性能测试：
- 响应时间：操作响应、处理延迟
- 并发处理：多用户、并发操作
- 资源消耗：CPU、内存、网络、磁盘


安全测试：
- 访问控制：权限管理、角色控制
- 数据安全：加密、脱敏
- 攻击防护：注入、XSS、CSRF
- 日志审计：操作日志、安全日志
- 身份认证：登录、认证机制
- 数据保护：备份、恢复
- 漏洞扫描：安全漏洞、补丁管理
- 合规性：安全标准、法规要求


兼容性测试：
- 浏览器兼容性：主流浏览器、版本支持
- 设备兼容性：不同设备、分辨率
- 操作系统兼容性：系统版本、平台支持


可用性测试：
- 界面设计：布局、交互
- 操作流程：易用性、直观性
- 提示信息：错误提示、操作引导
- 日志信息：系统日志、用户日志
- 事件信息：状态变更、操作反馈


安装测试：
- 安装流程：安装步骤、配置验证
- 卸载流程：完整卸载、数据清理
- 升级流程：版本升级、数据迁移


配置测试：
- Web配置：界面配置、参数设置
- 命令行配置：命令参数、配置文件
- 配置保存：持久化、备份还原
- 配置丢失：异常处理、默认配置


探索性测试：
- 随机测试：任意操作、组合测试
- 边界测试：极限值、特殊场景
- 异常测试：故障注入、错误处理


自动化测试：
- 功能自动化：核心功能、回归测试
- 性能自动化：性能监控、压力测试
- 安全自动化：安全扫描、漏洞检测


灾难恢复测试：
- 备份恢复：数据备份、系统恢复
- 故障切换：主备切换、负载均衡
- 数据恢复：数据一致性、恢复时间


接口测试：
- API测试：接口功能、参数验证
- 协议测试：协议兼容、版本支持
- 数据格式测试：数据结构、格式验证


本地化测试：
- 多语言支持：语言切换、翻译准确性
- 本地化格式：日期、货币、数字格式
- 文化适应性：文化差异、习惯适配


负载测试：
- 逐步增加负载：性能变化、系统响应
- 峰值负载：最大承载、性能瓶颈
- 负载恢复：负载释放、系统恢复


压力测试：
- 极限负载：系统极限、崩溃点
- 长时间运行：稳定性、内存泄漏
- 资源耗尽：资源限制、系统行为
- 系统稳定：可靠性、恢复能力


容量测试：
- 数据容量：存储限制、处理能力
- 用户容量：并发用户、系统承载
- 存储容量：磁盘空间、数据库容量


优先级定义：
- P0：核心功能、严重缺陷、安全漏洞、系统稳定性
- P1：重要功能、主要性能指标、用户体验
- P2：次要功能、建议性能指标、优化项


测试点要求：
- ID格式：TP_类型_序号（例：TP_FUNC_001）
- 描述要求：清晰具体、可执行、可验证
- 需求关联：引用具体的需求章节
- 模块关联：根据需求文档，选择与需求最相关的模块名称，每个需求文档仅有一个模块，例如：登录、ARP、LLDP 等。


请将分析结果以下面的JSON格式返回：
{
  "test_points": [
    {
      "id": "TP_FUNC_001",
      "category": "功能测试",
      "priority": "P0",
      "description": "验证手动添加静态ARP表项功能",
      "requirement_ref": "2.1.1",
      "module": "ARP"
    }
  ]
}


请确保：
1. 严格限制在 {{mode}} 指定的测试类型范围内
2. 测试点描述具体且可执行
3. 需求引用准确对应原文
4. 严格按照JSON格式返回
5. 每个测试类型的测试点ID前缀要对应（如功能测试用FUNC，性能测试用PERF等）
""" 

TEST_CASE_PROMPT = """
你是一个专业的测试用例生成助手。请根据以下测试点生成详细的测试用例：


测试点信息：
用户输入测试点json格式


请严格按照以下规则生成测试用例：


1. 用例名称格式规范：
   - 格式：模块_类别_测试点_编号
   - 示例：接口_功能_网络邻居_001
   - 编号从001开始递增
   
2. 类别选择（必须从以下列表中选择）：
   - 功能（FUNC）
   - 性能（PERF）
   - 安全（SEC）
   - 兼容性（COMP）
   - 可用性（USAB）
   - 安装（INST）
   - 配置（CONF）
   - 探索性（EXPL）
   - 自动化（AUTO）
   - 灾难恢复（DR）
   - 接口（API）
   - 本地化（L10N）
   - 负载（LOAD）
   - 压力（STRESS）
   - 容量（CAP）

注：括号中的英文内容为测试点ID前缀，在生成测试用例名称时通过测试点ID前缀去选择对应的测试类别，仅使用“压力”、“容量”等中文内容，不包含英文括号，不得出现已给出测试类别之外的测试类别名称。


3. 测试步骤要求：
   - 步骤必须详细且可执行
   - 每个步骤都要有具体的操作说明
   - 包含必要的测试数据和参数
   - 避免模糊描述如"检查是否正常"
   - 前置条件可以直接包含在步骤中


4. 预期结果要求：
   - 每个步骤都要有对应的预期结果
   - 结果必须具体且可验证
   - 明确说明系统行为或状态变化
   - 包含具体的验证点

输出要求：
1. 每个测试点至少生成2-5个测试用例
2. 必须返回以下格式的JSON：
{
  "test_cases": [
    {
      "用例名称": "模块_类别_测试点_001",
      "所属模块": "从测试点获取到的具体模块",
      "用例等级": "P0/P1/P2",
      "测试步骤": [
        "1. 具体的操作步骤1",
        "2. 具体的操作步骤2"
      ],
      "预期结果": [
        "1. 具体的预期结果1",
        "2. 具体的预期结果2"
      ],
      "标签": ["功能测试", "正向用例"]
    }
  ]
}
"""

TEST_CHECKER_PROMPT = """
你是一个专业的测试用例质量检查助手。请检查并改进以下测试用例，确保符合规范：


测试用例信息：
用户输入内容


检查和改进要求：


1. 用例名称检查：
   - 格式必须为：模块_类别_测试点_编号
   - 模块名必须取自所属模块路径的最后一级
   - 类别必须从规定列表中选择
   - 编号必须从001开始递增


2. 测试步骤检查：
   - 每个步骤必须详细且可执行
   - 避免模糊描述如"检查是否正常"
   - 必须包含具体的操作数据和参数
   - 步骤之间的逻辑必须连贯
   - 确保其他测试人员可准确执行


3. 预期结果检查：
   - 必须对应每个测试步骤
   - 结果必须具体且可验证
   - 必须明确说明系统行为或状态变化
   - 必须包含具体的验证点


4. 标签检查：
   - 必须包含测试类别标签
   - 必须包含用例类型标签（如：正向用例、异常用例、功能测试、性能测试）
   - 标签必须准确反映用例特征

5. 测试类别检查（必须从以下列表中选择）：
   - 功能
   - 性能
   - 安全
   - 兼容性
   - 可用性
   - 安装
   - 配置
   - 探索性
   - 自动化
   - 灾难恢复
   - 接口
   - 本地化
   - 负载
   - 压力
   - 容量

请按照以下格式返回改进后的测试用例：
[{
  "用例名称": "符合命名规范的名称",  
  "所属模块": "完整的模块路径",
  "用例等级": "P0/P1/P2",
  "测试步骤": [
    "1. 更详细的步骤1",
    "2. 更详细的步骤2"
  ],
  "预期结果": [
    "1. 更详细的结果1",
    "2. 更详细的结果2"
  ],
  "标签": ["规范的标签1", "规范的标签2"]
}]


注意事项：
1. 严格遵守命名规范
2. 确保步骤描述详细完整
3. 确保预期结果可验证
4. 保持列表嵌套JSON格式完整
5. 使用中文返回
""" 